The "Unit Test" GitHub Actions workflow uses the "codecov/codecov-action" GitHub Actions action to upload coverage data
to Codecov.

Previously the workflow specified the "v1" version ref for the action dependency. That pinned the dependency to the
major version 1 series. Several major version bumps have been made in the action since that time so the use of the v1
ref caused the workflow to use a significantly outdated and deprecated version of the action.

Bumping the action to the latest "v3" ref will avoid the potential for the step to stop working entirely (the action
docs claim v1 was sunset 1.5 years ago) and allow the workflow to benefit from the enhancements and fixes from ongoing
development work in the action until such time as a breaking change in the action triggers them to make another major
version bump. At that time it will be necessary for the project maintainers to evaluate whether the breaking change
requires any modifications to the workflow before manually bumping the ref again (i.e.,
`uses: codecov/codecov-action@v3` -> `uses: codecov/codecov-action@v4`).

… workflow

Codecov claims a token is not needed when using the codecov/codecov-action GitHub Actions action in workflows of a
public repository:

https://github.com/codecov/codecov-action#usage

> For public repositories, no token is needed

However, experience shows that that step of the workflow is subject to intermittent spurious failures caused by a 404
error during the upload attempt:

```
[2023-06-26T09:18:51.453Z] ['error'] There was an error running the uploader: Error uploading to https://codecov.io: Error: There was an error fetching the storage URL during POST: 404 - {'detail': ErrorDetail(string='Unable to locate build via Github Actions API. Please upload with the Codecov repository upload token to resolve issue.', code='not_found')}
```

It is suggested that this can be avoided by providing the upload token:

https://community.codecov.com/t/upload-issues-unable-to-locate-build-via-github-actions-api/3954

It should be noted that PRs from forks do not have access to repository secrets, so the approach suggested there of
using an encrypted repository secret for the token would mean that PRs from forks (the workflow runs for which don't
have access to secrets) would still be subject to the same intermittent spurious workflow run failures.

The alternative approach is to add the token in plaintext directly in the workflow. The security implications of that
approach are described here:

https://community.codecov.com/t/upload-issues-unable-to-locate-build-via-github-actions-api/3954

> Public repositories that rely on PRs via forks will find that they cannot effectively use Codecov if the token is
> stored as a GitHub secret. The scope of the Codecov token is only to confirm that the coverage uploaded comes from a
> specific repository, not to pull down source code or make any code changes.
>
> For this reason, we recommend that teams with public repositories that rely on PRs via forks consider the security
> ramifications of making the Codecov token available as opposed to being in a secret.
>
> A malicious actor would be able to upload incorrect or misleading coverage reports to a specific repository if they
> have access to your upload token, but would not be able to pull down source code or make any code changes.

We have evaluated the risks of exposing the token and are intentionally choosing to accept the possibility of it being
used by a malicious actor to upload incorrect coverage data for this project to Codecov.